Are you talking about server CPU usage or client?
Also consider enabling the profiler (see minetest.conf.example or main menu settings) to gather some execution time results. If mesecons takes much time to execute a step, then it's probably a mesecons issue, otherwise it's likely that Minetest needs time to prepare the new mapblocks for rendering.

Are you talking about server CPU usage or client?
Also consider enabling the profiler (see minetest.conf.example or main menu settings) to gather some execution time results. If mesecons takes much time to execute a step, then it's probably a mesecons issue, otherwise it's likely that Minetest needs time to prepare the new mapblocks for rendering.

Thank you very much for your reply. I did mean the server's CPU usage and since I wasn't sure on how to use the profiler to trace down lag sources... We did it when both the device was off and then when it was on. With the same exact person in the same exact in game location. So the variation that the mapblock needed time to render should not have existed, since this was server sided we noticed and we did our best to limit variables as humanly possible.

Fast (with delay of one globalstep dtime) gate oscillations are forbidden by overheats. Pistons are indeed lacking this.
Btw. here's a screenshot (from another issue, but shows the subject):

Fast (with delay of one globalstep dtime) gate oscillations are forbidden by overheats. Pistons are indeed lacking this.
Btw. here's a screenshot (from another issue, but shows the subject):

So what your saying everything but pistons are "throttled" by "overheat"? If so could we implement that or something similar to prevent piston based lag machines from being as easily produce able in game? Because as I said it would only takes about 50 of these to max out a core according to our testing of a single clock similar to the one above.

So what your saying everything but pistons are "throttled" by "overheat"?

Try connecting a not gate's output with its input. After a short time it will drop.
See also:

If so could we implement that or something similar to prevent piston based lag machines from being as easily produce able in game?

The best thing to do is probably to use mesecons.do_overheat (and overheat group) for pistons and swap them with an overheated version. The overheated piston should then not react to mesecons and after a node timer that was started when the overheated piston is constructed runs out, the overheated piston should be swapped to a normal piston again and updated to the current mesecons signal state.

Feel free to make a PR! ; ) (But note that this might be a bit more difficult than described.)

So what your saying everything but pistons are "throttled" by "overheat"?

Try connecting a not gate's output with its input. After a short time it will drop.
See also:

mesecons/mesecons_gates/init.lua

Lines 29 to 32 in 9b58f8d

	if mesecon.do_overheat(pos) then
	minetest.remove_node(pos)
	mesecon.receptor_off(pos, gate_get_output_rules(node))
	minetest.add_item(pos, gate.drop)

If so could we implement that or something similar to prevent piston based lag machines from being as easily produce able in game?

The best thing to do is probably to use mesecons.do_overheat (and overheat group) for pistons and swap them with an overheated version. The overheated piston should then not react to mesecons and after a node timer that was started when the overheated piston is constructed runs out, the overheated piston should be swapped to a normal piston again and updated to the current mesecons signal state.

Feel free to make a PR! ; ) (But note that this might be a bit more difficult than described.)

Thanks for the information but please do keep in mind that I meant to highlight and bring up this situation on my server so people can refer to this issue and help reach a solution for the mod itself.

Which can then be applied to my and all other operating Minetest servers which are based on this mod. So hopefully someone can help us here to resolve the situation sooner or later.

See also #406

I’d suggest limiting piston speed instead of overheating. Sadly that’s a breaking change, there may be machines relying on instant action (I don’t remember ever seeing that actually... except of my own machines =)

I’d suggest limiting piston speed instead of overheating. Sadly that’s a breaking change, there may be machines relying on instant action (I don’t remember ever seeing that actually... except of my own machines =)

Exactly and indeed better than letting people easily exploit servers' CPU resources I am not right? Even Minecraft's Redstone is throttled to allow per redstone tick which in Minecraft was every 2 in game ticks which is equal to 10ms.

I think that can be configurable with possibility to keep the current behavior.

Your issue may be solved by third-party mods that provide management of the cpu-resources consumed by this mod,
for example: mesecons_debug

Your issue may be solved by third-party mods that provide management of the cpu-resources consumed by this mod,
for example: mesecons_debug

Hey thanks for the suggestion however, checking this mod awhile ago and even now it doesn't appear to have a clear understanding of the hard coded limitation in place per mapblock and currently lack any configurations by this mod.

See PR